[レポート] データレイク構築の際に考慮すべき5つのポイント #DEM19-S #reinvent

こんにちは。 DA部プリセールスエンジニアの兼本です。

本エントリでは、データレイク構築の際に考慮すべき5つのポイントに関するetleap社のショートセッション「AWS re:Invent 2019: Five data lake considerations w/ Amazon Redshift, Amazon S3 & AWS Glue (DEM19-S)」のレポートをいたします。

セッション情報

登壇者

• Sudhir Gupta / Sr. Partner Solutions Architect - Redshift Specialist , Amazon Web Services
• Christian Romming / Founder & CEO , Etleap

概要

セッション概要：
Building a data lake can be a headache. More often than not, they end up becoming data swamps—bottomless pits that suck up development resources and obscure data transparency. But when done correctly, data lakes can be valuable wells of knowledge that transform your business. Join Etleap and the Amazon Redshift team as we take a deep dive into the issues that plague data lake creators. We give you five refreshing pointers for keeping the development workload sustainable and ensuring data usability for the long term. This presentation is brought to you by Etleap, an APN Partner.

（抄訳）データレイクの構築は頭痛の種になります。多くの場合、データレイクは最終的に開発リソースを吸い込み、データの透明性を曖昧にする底なしのデータの沼地になります。しかし、適切に構築すれば、データレイクはビジネスを変革する貴重な知識の宝庫になります。EtleapとAmazon Redshiftのチームがデータレイククリエーターを悩ませている問題を深く掘り下げ、開発ワークロードを維持し、長期にわたってデータの有用性を確保するための5つのさわやかなポインタを提供します。このプレゼンテーションは、APNパートナーであるEtleap社によって提供されます。

動画

内容

このセッションでは、データレイクを沼地（Swamp）にすることなく、分析に最適化するために考慮することを説明します。

多くのデータレイクがこのような構成を持ちます。これが最初の状態です。

• Raw Zone：
  • 様々なデータソースから取得した状態のままのデータ
  • 粒度もバラバラで分析するのに前処理が必要
• Curated Zone：
  • 分析に最適化されたデータ

Raw ZoneとCurated Zoneの間には高い山があります。（データ「レイク」なのに、と思ったのは内緒です。）アナリストが必要としているのは、Curated Zoneにある分析に最適化されたデータですが、それを得るためには、

• データのクレンジング
• （パフォーマンス向上のため）データをパーティショニング
• データの品質向上
• ファイルの圧縮
• フォーマット変換（トランスフォーメーション）
• データの意味が適切かを考察

といったエンジニアリングの作業もしなければなりません。

スライド下部の点線のようなアクセスです。

提案1：すべてのデータに最小限のスキーマを与えて、探索できるようにする

Raw Zoneにはファイルやデータベーステーブルなど、さまざまな状態のデータが格納されていると思いますが、すべてのデータに最低限のスキーマを設定し、SQLでアクセスできるようにしましょう。
それには、HIVE、Presto、Athena、Redshift Spectrumなどを使うことができます。

この段階では、パフォーマンスやデータの意味的正しさを考慮する必要はなく、とにかくデータの探索ができるようにすることが重要です。

提案2：データキュレーションのエンジニアリングを削減または排除する努力をする

Raw Zoneのデータにアクセスできたとして、アナリストが欲しいデータを得るためにはエンジニアリングが必要な場合もあります。
しかし、エンジニアリングチームはたくさんのタスクを抱えていることが多く、すぐに対応してもらえるとは限りません。
また、アナリストが欲しいデータはビジネスに関する知識が必要なものがあります。ビジネスルールに関してはエンジニアよりもアナリストのほうが詳しいことが多いです。

なので、アナリストが自分自身でデータキュレーション（データトランスフォーメーション）できる環境を用意することが重要です。
ちょうど上図のRow ZoneとCurated Zoneの間に設置されたパイプのようなイメージです。

提案3：アナリスト向けにマテリアライズドビューの作成をセルフサービス化する

データトランスフォーメーションは、aws の場合は、glueを使うことができますが、データキュレーションプロセスを効率よく行うには、再利用できるようにいくつか考慮すべきポイントがあります。

• 再利用可能なプロセスの例
  • イベントストリームの圧縮
  • 低レイテンシの小さなバッチファイル、アーカイブ用の大きなファイル
  • 挿入、更新、削除の統合
  • 最新のポイントインタイムスナップショットの配信
  • パイプライン監視
  • データ配信のタイミングと品質を満たすSLA

この段階では、アナリストが自分自身でビューを作成したり、あるいは特定分野の分析に特化したデータマートを作成するかもしれません。

提案4：データウェアハウスとデータレイクを統合する

（ここからスピーカーがSudhir Gupta氏に交代します）

さて、実際の運用では、すべてのデータをデータウェアハウス（Redshift）に格納せず、一部のデータはS3のストレージに配置して、外部データセットとして利用するかもしれません。これを可能にするのが、Redshift Spectrumです。

Redshift Spectrumを利用することで、S3に配置されたCSV、TSV、parquetファイルなどに対しても、通常のRedshiftと同様にSQLクエリを使用してアクセスすることができます。

また、データレイクの構築に関しては、以下を考慮する必要があります。

• データレイクの設計原則
  • 使用される一般的なクエリフィルターと整合するキーでデータをパーティション分割します。
  • これにより、パーティションの整理が可能になり、クエリのパフォーマンスが向上します。
• ファイルサイズ
  • Amazon S3の往復を減らすためにオプションのファイルサイズを選択します。
  • 推奨は、パーティションごとに256 MBから1 GBの列形式のファイルです。
• 圧縮
  • 上記のファイルサイズでデータを取得するために、スケジュールに基づいてデータを圧縮します。
  • 例：1時間ごとのファイルが小さい場合、日次処理にします。
• データを取得する場所と頻度を決定します。
  • ニーズに合った頻度とデータ取得メカニズムを選択します。

提案5：適切な権限を設定してデータを保護する

5つ目の提案として、S3とRedshiftにおけるデータアクセスの権限があります。

S3では以下の設定が可能です。

S3のセキュリティ設定に関しては、re:Invent 2019で発表されたアップデートである、Access Analyzer for S3を使用するのも効果的ですね。

新機能のAccess Analyzer for S3を利用して誤ったS3の公開を止める！ #reinvent

また、Redshiftでは以下の設定が可能です。

まとめ

最後のまとめとして、eltleapによるデータパイプラインプロセスの簡素化、自動化の紹介がありました。

このセッションではソリューションとしてetleapを紹介していましたが、同様のお悩みをお持ちの方は多いと思いますので、データパイプラインはデータの沼地を作らないために重要な役割を果たしそうな予感がします。

最後まで読んでいただきありがとうございました。